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FOREWORD 


This is one of a set of seven reports, each one describing the 
results, for a particular subsystem, of a study titled "An Engineering 
Study of Onboard Checkout Techniques. " Under the general title of 
"A Guide to Onboard Checkout, " the reports are as follows. 
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of the NASA Manned Spacecraft Center. The guidance and support 
given to the study by him and by other NASA personnel are gratefully 
acknowledged. 
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Section 1 


INTRODUCTION 


1.1 OBJECTIVE 


With the advent of large scale aerospace systems, designers have recognized 
the importance of specifying and meeting design requirements additional to the 
classical functional and environmental requirements. These "additional" require- 
ments include producibility, safety, reliability, quality, and maintainability. 

These criteria have been identified, grown into prominence, and become disciplines 
in their own right. Presently, it is inconceivable that any aerospace system/ 
equipment design requirements would be formulated without consideration of 
these criteria. 

The complexity, sophistication and duration of future manned space missions 
demand that still another criterion needs to be considered in the formulation of 
system/equipment requirements. The concept of "checkoutability" denotes the 
adaptability of a system, subsystem, or equipment to a controlled checkout pro- 
cess. As with other requirements, it should also apply from the time of early 
design concept formulation. 

The results of "An Engineering Study of Onboard Checkout Techniques" and 
other studies indicate that for an extended space mission onboard checkout is 
mandatory and applicable to all subsystems of the space system. In order to use 
it effectively, "checkoutability" should be incorporated into the design of each 
subsystem, beginning with initial performance requirements. 

Conferences with researchers, system engineers and subsystem specialists 
in the course of the basic Onboard Checkout Techniques Study revealed an extensive 
interest in the idea of autonomous onboard checkout. Designers are motivated to 
incorporate "checkoutability" into their subsystem designs but express a need for 
information and guidance that will enable them to do so efficiently. 

It is the objective of this report to present the results of the basic study as 
they relate to one space subsystem to serve as a guide, by example, to those who 
in the future need to implement onboard checkout in a similar subsystem. It is not 
practicable to formulate a firm set of instructions or recipes, because operational 
requirements, which vary widely among systems, normally determine the check- 
out philosophy. It is suggested that the reader study this report as a basis from 
which to build his own approach to "checkoutability. " 
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1 . 2 BASIC STUDY SUMMARY 


1. 2. 1 STUDY OBJECTIVE 

The basic study was aimed at identification and evaluation of techniques for 
achieving the following capabilities in the operational Space Station/Base, under 
control of the Data Management System (DMS), with minimal crew intervention. 

• Automated failure prediction and detection 

• Automated fault isolation 

• Failure correction 

• Onboard electronic maintenance 

1.2.2 STUDY BASELINE 

The study started in July 1970. The system design baseline was established 
by the Space Station Phase B study results as achieved by the McDonnell-Douglas/ 
IBM team, modified in accordance with technical direction from NASA-MSC. The 
overall system configuration was the 33-foot diameter, four-deck, 12-man station. 
Individual subsystem baseline descriptions are given in their respective "Guide to 
Onboard Checkout" reports. 

1.2.3 STUDY TASKS 

The basic study comprised five tasks. Primary emphasis was given to 
Task 1, Requirements Analysis and Concepts. This task established subsystem 
baseline descriptions and then analyzed them to determine their reliability/ main - 
tainability characteristics (criticality, failure modes and effects, maintenance 
concepts and line replaceable unit (LRU) definitions), checkout strategies, test 
definitions, and definitions of stimuli and measurements. After software pre- 
liminary designs were available, an analysis of checkout requirements on the DMS 
was performed. 

A software task was performed to determine the software requirements 
dictated by the results of Task 1 . 

Task 3 was a study of onboard electronic maintenance requirements and 
recommendations of concepts to satisfy them. Supporting research and technology 
tasks leading to an onboard maintenance capability were identified. The study 
implementation plan and recommendations for implementing results of the study 
were developed in Task 4. The task final report also summarizes results of the 
study in all technical tasks. 
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Reliability, Task 5, was very limited in scope, resulting in an analysis of 
failure modes and effects in three Space Station subsystems, GN&C, DMS (computer 
group) and RF communications. 

1.2.4 PREVIOUS REPORTS 

Results of the basic study were reported by task in the following reports, 
under the general title of "An Engineering Study of Onboard Checkout Techniques, 
Final Report. " 


IBM Number 

Title 

71W-00111 

Task 1: Requirements Analysis and Concepts 

71W-00112 

Task 2: Software 

71W-00113 

Task 3: Onboard Maintenance 

71W-00114 

Task 4: Summary and Recommendations 

71W-00115 

Task 5: Subsystem Level Failure Modes and 
Effects 
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Section 2 


BASELINE SUBSYSTEM DESCRIPTIONS 


2. 1 GENERAL 

This section describes the baseline Structures and Mechanical Subsystem 
which was analyzed to define onboard checkout requirements. In order to assess 
requirements for onboard checkout, descriptions at the subsystem level and the 
assembly level are required, as well as the major interfaces between subsystems. 

The assembly level description for each of the subsystems (MSEC -DRL- 160, 
Line Item 13) provided the primary working document for subsystem analysis. To 
reduce documentation, these documents have been incorporated by reference into 
this report, where applicable. Therefore, where no significant differences exist 
from the Phase B definition, this report contains a brief subsystem description 
and an identification of the referenced document containing the assembly level 
descriptions for that subsystem. Where significant differences do exist, the sub- 
system level description includes these changes in as much detail as is available. 
MSFC-DRL-160, Line Item 19, provided the major subsystem interface descrip- 
tions for analysis of integrated test requirements. 

2. 2 SYSTEM LEVEL DESCRIPTION 


The Space Station structure consists primarily of four subsystem areas 
which will require checkout support. They are: 

• Basic Structure 

• Docking Mechanisms 

• Spacecraft Access 

Hatches 
Airlocks 
View Ports 

• Antenna Deployment Mechanisms 
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2.2.1 BASIC STRUCTURE 


The basic Space Station structure provides the necessary pressurized habitat, 
equipment support, meteoroid protection, radiators, insulation, and docking inter- 
faces. Attainment of the required volume for the accommodation of crew, experi- 
ments, and subsystems within a 110, 000-pound weight limit demands that the 
structure design be optimized. The structure must also have adequate factors of 
safety to satisfy the long life (ten years) requirements. The design uses state-of- 
the-art materials, design, and fabrication techniques. 

The external cylindrical pressure shell and the center tunnel structure are 
2219 aluminum alloy with integrally machined waffle stiffeners on the external 
shell and integral stabilizing rings on the tunnel. Each two-deck module is closed 
at each end with a toroidal dome membrane. The equipment in each module is 
supported by the deck structure located halfway between the domes. The deck is 
formed by a radial array of beams extending from the center tunnel to the external 
pressure shell. The thrust loads in the center tunnel structure are carried to the 
external pressure shell structure through a conic structure at the forward end of 
the station. 

ECS radiator, thermal insulation, meteoroid protection, and a pressure 
shell are integrated into a 4. 5 inch thick sandwich design. The external surface 
of 0. 020-inch beaded aluminum sheet serves the dual function of being both the 
primary meteoroid bumper and the radiating surface for the ECS radiator. An 
inner, 0. 010-inch corrugated aluminum sheet provides additional meteoroid pro- 
tection and limits insulation blanket damage over the 10-year life. The two 
bumpers are supported by 1 section aluminum extrusions which contain dual pas- 
sages for the ECS radiator fluid. The 0. 110-inch, waffle stiffened pressure shell 
forms the interior surface of the sandwich. Tests of this design at the MDAC 
light gas gun facility have indicated that the no meteoroid puncture probability of 
the pressure shell is 0. 985 for ten years. 

2. 2. 2 DOCKING MECHANISM 

The docking mechanism accomplishes the physical alignment of the vehicles, 
attenuates the relative closing velocities, and captures and rigidizes the two ve- 
hicles. In addition to the mating of the two vehicles, the system must accomplish 
the disconnection, detachment, and separation of the spacecraft from the Space 
Station. 
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The conceptual design prepared for the docking mechanism and shock ab- 
sorber/actuator is described as follows. A gas spring is used for energy absorp- 
tion so that the pressure can be varied to accommodate wide variations in the 
masses of the vehicles to be docked. A floating piston separates the gas from a 
low temperature hydraulic fluid. As the shock absorber strokes, the hydraulic 
fluid flows through a one-way valve and drives the floating piston down the shock 
absorber, doing work against the gas pressure. When the compression stroke is 
completed, the one-way valve prevents the shock absorber from springing back. 

A small bypass orifice permits it to return at a slow, controlled rate to its initial 
extended length. The gas spring pressure can then be reduced for retracting the 
frame to the stowed position. 

2.2.3 ACCESS HATCHES, AIRLOCKS, VIEWPORTS 

In the evolution of the Space Station configuration, the requirement for crew 
access to the various compartments, docked modules, external portions of the 
station, and consideration of redundant transfer paths in case of emergencies is 
essential for crew safety considerations. While normal crew activities and access 
to experiment and cargo modules will be accomplished in a shirtsleeve environ- 
ment, some contingency operations will require pressure suit and airlock transfer 
capabilities. 

The requirement for two separately pressurized volumes has been provided 
by the two-deck, common module design approach; in addition, the 10-foot-di- 
ameter center tunnel provides a third pressure volume. The expendables com- 
partment is normally unpressurized except for shirtsleeve access for maintenance 
and repair. The forward portion of the center tunnel can be used as an airlock if 
necessary. 

Each deck will have a 5-foot-diameter clear opening access hatch into the 
tunnel. These hatches will be open for the normal traffic flow, but, in cases of 
emergency, may be closed and sealed against fire, contamination, or depressur- 
ization in one of the common modules. If one of the common modules is depres- 
surized, the tunnel environment will be referenced to the other common module 
environmental control system. Using pressure suits, the crew may then reenter 
the depressurized module for inspection and repair through the fixed airlock. 

This airlock will also permit access to the outside of the Space Station from either 
of the common modules for normal EVA activities. 
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2. 2. 4 ANTENNA DEPLOYMENT MECHANISM 

The Space Station requires four 15-foot diameter communications antennas 
to provide high-gain RF acquisition and continuous tracking of relay satellites. 
These antennas are stowed during launch under the nose fairing together with the 
artificial-g telescoping spoke. Upon reaching orbit and ejection of fairings, the 
antenna mounting booms shall be extended and locked in operating position until 
artificial gravity operation. The antenna mounting boom requires the capability 
of being retracted and locked in a low inertia position during the artificial gravity 
mode. The antenna shall have a two-axis gimbal positioner located at the antenna 
end of the mounting boom. The azimuth axis shall be parallel to the Space Station 
Z axis. Each antenna shall be capable of scanning 360 degrees in azimuth and 
from +75 degrees to -10 degrees in elevation. During maintenance, the antennas 
shall be retracted to air lock ports where the back side of the antenna is accessible 
to intervehicular astronauts. The antenna locations shall be 45 degrees off the 
major Y-Z axes. The antenna masts are fixed length and actuated by an electric 
motor drive train located at the hinge line. Flexible power and signal leads must 
be provided at the hinge to provide power to the antenna drive and to transmit 
position signals. In addition, a swivel type waveguide must be provided at the mast 
hinge line. 

2.3 ASSEMBLY LEVEL DESCRIPTIONS 


Space Station MSFC-DRL-160, Line Item 8, Volume V, Book Mechanical, 
contains a description of the mechanical subsystem elements sufficiently detailed 
for checkout requirements analysis purposes and will become the primary work- 
ing document for this purpose. MSFC-DRL-160, Line Item 8, Volume V, Book 6, 
is incorporated into this report by reference. 
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Section 3 

RELIABILITY AND MAINTAINABILITY ANALYSES 

3.1 CRITICALITY ANALYSIS 

As a guide to emphasis in subsequent checkout technique studies, an analysis 
has been made of the overall subsystem and major component criticality (failure 
probability) of the Space Station subsystems and equipment. As an input to the 
Checkout Requirements Analysis Task, this data along with the failure mode and 
effects data will be useful in determining test priorities and test scheduling. 
Additionally, this data will aid in optimizing checkout system design to ensure 
that confidence of failure detection is increased in proportion to added system 
complexity and cost. 

3. 1. 1 CRITICALITY ANALYSIS PROCEDURE 

A criticality number (related to failure probability) was generated for each 
major subsystem component. This number is the product of: (1) the component 
failure rate (or the reciprocal of mean-time-between-failure), (2) the component’s 
anticipated usage or duty cycle, and (3) an orbital time period of six months, or 
4, 380 hours. Six months was chosen as the time period of interest to allow one 
missed resupply on the basis of normal resupply occurring at three-month intervals. 
The criticality number, then, is the failure expectation for a particular component 
over any six-month time period. 

For visibility, the major components of each subsystem analyzed have been 
ordered according to the magnitude of their criticality numbers. This number, 
however, should not be considered as an indication of the real risk involved, since 
it does not take into account such factors as redundant components, subsystem 
maintainability, and the alternate operational procedures available. 

Overall subsystem criticality has been determined by a computerized 
optimization process whereby spares and redundancy are considered in terms of 
a trade-off between increased reliability and weight. This determination, there- 
fore, reflects not only the failure probability of subsystem components, but also 
the probability that a spare or redundant component may not be available to 
restore the subsystem to operational status. The methodology used is described 
in Section 9, Long-Life Assurance Study Results, DRL 13 (Preliminary Subsystem 
Design Data), Volume III (Supporting Analyses), Book 4 (Safety/Long Life/Test 
Philosophy) from the MDAC Phase B Space Station Study. Component -level failure 
mode and criticality data are presented in subsequent paragraphs. 
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3.1.2 SUBSYSTEM CRITICALITY DATA 


Reliability for the Structural and Mechanical Subsystem for six months is 
0. 995 and requires 75 pounds of seals and meteoroid patches to achieve. This 
equates to a subsystem criticality numeric of 5 x 10 _ 3 for each six-month orbital 
interval. This value implies that there is a 0. 5 percent risk that adequate spares 
will not be available when required or that a puncture in the pressure shell will 
occur that cannot be repaired. Component-level criticality numbers in Table 3-1 
were estimated directly since conventional mean-time-between-failure numerics 
are not appropriate for structural components. 

3.2 FAILURE EFFECTS ANALYSIS 

Based upon the baseline subsystem descriptions, each major subsystem com- 
ponent was assessed to determine its most probable failure mode(s), and the 
"mission effect" associated with this failure mode(s). The "mission effect" is 
noted to provide a brief explanation of Space Station behavior if the particular 
failure mode should occur (e. g. , experiments degraded, crew hazard, etc.). 

The explanation generally does not, however, consider the offsetting effects of 
backup redundancy or spares since there would be practically no effect if these 
factors were considered. 

In addition, the effect of failure is categorized into the following criticality 
classes: 

(a) Category I - Failure could cause a loss of life. 

(b) Category II - Failure could cause the loss of a primary mission 
objective. 

(c) Category III - Failure could cause the loss of a secondary mission 
objective. 

(d) Category IV - Failure results in only a nuisance. 

In most cases, Category II and Category III failures are not distinguishable 
because primary and secondary mission objectives have not been identified to the 
level of detail required to permit such separation. 

Component level failure mode and criticality classification data are shown 
in Table 3-2. 
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Table 3-1. Structures Subsystem Criticality Ranking 


Component 

Single Unit 
Criticality 
(10-6) 

Conditioned 
Loss Criticality 
(10-6) 

Remarks 

Primary Structure 

1,000 

500 

Considers that 1/2 the risk can be negated by 
patching meteoroid penetrations, utilizing makeup 
C >2 for leakage, and stopping meteoroids with the 
meteoroid shield 

Radiator 

1,000 

500 

Considers that 1/2 the risk can be deleted by re- 
placing segments and isolating leaks 

View Port Seals 

500 

100 

Leakage can be made up by emergency O 2 

Tunnel Hatches 

500 

100 

Redundant seals and more than one exit from 
compartment exist 

Docking Ports 

360 

10 

Considers repair of docking ports plus capability 
of docking at any port if one docking mechanism 
is damaged 

Main Airlock 

300 

10 

Replaceable seals and makeup O 2 . EVA can also 
be accomplished via forward section 

Antenna Deployment 
Mechanism 

100 

10 

Provides for less than optimum coverage if one 
antenna is out and EVA to repair 

Fairings 

100 

10 

EVA can release 
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Table 3-2. Structure Subsystem 


Major 

Subsystem 

Component 

Failure 

Mode(s) 

Mission 

Effect 

Failure 

Category 

No. of 
Units 

(A) 

MTBF/Source 
Thousands 
of Hours 

(B) 

Duty 

Cycle 

{%) 

Criticality 

Unit 

(4380 hrs X 
B/A X 10- 6 ) 

Primary Structure 

Meteoroid penetra- 
tion 

Docking collision 
Shrapnel from 
pressure vessel 
rupture 

Loss of mission 
objectives & 
crew safety but 
are secondary 
failures 

I 



100 

1,000 

Viewport Seals 

Leakage 

Cat. I - gross 
leakage would 
require crew 
evacuation of 
a compartment 

n 

7 


100 

500 

Tunnel Hatches 

Leakage 
Jammed closed 
Jammed open 

Cat. I - crew 
safety hazard if 
one compartment 
were contamin- 
ated or on fire 

i 

5 


100 

500 

Docking Ports 

Leakage 
Docking colli- 
sion 

Cat. I - crew 
safety if exten- 
sive rupture 
occurs requir- 
ing immediate 
crew evacuation 
of a compartment 

i 

7 


100 

360 



Table 3-2. Structure Subsystem (Continued) 


Major 

Subsystem 

Component 

Failure 
Mode (s) 

Mission 

Effect 

Failure 

Category 

No. of 
Units 

(A) 

MTBF/Source 
Thousands 
of Hours 

(B) 

Duty 

Cycle 

(%) 

Criticality 

Unit 

(4380 hrs X 
B/A X 10“ 6 ) 

Antenna Deploy- 
ment Mechanism 

Servo motor 
shorts 

Loss of optimum 
coverage 

III 

4 

— 

1 cy. 

400 

Main Airlock 

Leakage 

Rupture 

Loss of normal 
EVA egress & 
ingress route 

II 

1 

— 

100 

300 

Radiator 

Leakage 

Burst 

Experiment loss 
or curtailment 

n 

1 

— 

100 

1,000 

Fairings 
(Nose Cone) 
(Sensors) 

Won't separate 
Hangup 

Loss of prime 
experiments 
Loss of auto- 
matic control 

ii 

4 


1 cy. 

100 



3.3 MAINTENANCE CONCEPT ANALYSIS 


Maintenance concepts defined for Space Station subsystems are intended to 
facilitate their preservation or restoration to an operational state with a minimum 
of time, skill, and resources within the planned environment. General maintenance 
concepts and analyses are summarized in Section 7. 

3.4 LINE REPLACEABLE UNIT ANALYSIS 


General guidelines and criteria for the definition of LRUs were established 
and these along with the maintenance philosophies reported in Section 3. 3 were 
used to determine at what level line maintenance would be performed. For the 
Space Station subsystems specific justification applicable to LRU selection for the 
particular subsystem under examination was derived from the guidelines and these 
justifications are presented along with the LRU listing. The "functional LRUs" 
were then considered in the light of thp standard electronic packaging scheme and 
actual LRUs were defined and listed. The method employed and the results 
achieved are discussed for both cases in the following sections. 

The definition of Line Replaceable Units (LRUs) is keyed to repairing sub- 
systems in an in-place configuration with the LRU being the smallest modular unit 
suitable for replacement. General factors considered in identifying subsystem 
LRUs include: (1) maintenance concepts developed and defined in Section 3.3; 

(2) the component-level failure rates delineated in the criticality analyses of 
Section 3. 1; (3) the amount of crew time and skill required for fault isolation 
and repair; (4) resultant DMS hardware and software complexity; and (5) subsystem 
weight, volume, location, and interchangeability characteristics. Listings of LRUs 
and more specific justification for their selection follows. 

Selection of LRUs for the Structures Subsystem is based primarily upon 
specific failure characteristics of subsystem comments. The selection has also 
been based upon a replacement level which can be accomplished with ordinary 
tools and skills, and without a requirement for precision alignment and/or special 
processes, environment, or facilities. The analysis has resulted in the LRU list 
shown in Table 3-3. 

The LRUs defined fall into the following general failure categories: 

• Soft parts subject to scuffing, wear, puncture, possible age degradation, 
or other surface marring. Examples include hatch seals, struts with "O" 
rings, the inflatable airlock, and view port windows. 

• Items subject to physical damage from outside physical impact/collision 
(e. g. , docking) or misuse. Examples include docking latches, the antenna 
boom, the complete hatch assembly, and isotope unit handling aids. 
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• Functional electromechanical units which, during the ten-year life of 
the Space Station, could experience unexpected wear or internal part 
failure. Examples include the despin module antirotation drive unit, 
the antenna boom drive unit, the cargo handling hoist assembly, and 
the electric drive unit used in handling the isotope. 


Table 3-3. Structures 


LRU 

Quantity 

Docking Mechanism Shock Struts 

64 

Docking Port Inflatable Seals 

14 

Hatches and Airlock Doors Inflatable Seals 

18 

Inflatable Airlock 

1 

View Port Window Assembly 

25 

Hatch Temperature Indicators 

32 

Hatch Pressure Indicators 

32 

Hatch Assembly 

16 

Despin Module Drive Unit 

1 

Cable Deployment Module Drive 

1 

Docking Port Seal Latches 

32 

Antenna Boom 

4 

Antenna Boom Drive Unit 

4 

Cargo Handling Hoist 

2 

Cargo Hoist Cable 

2 

Electric Drive Unit, Isotope System Handling 

2 

Handling Aids, Isotope System 

4 
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Table 3-3.. Environmental Control and Life Support 


LRU 

Quantity 

„ . , Standby 

Required Redundant 

High Pressure Gas Tank 

12 


Flow Restrictor 

30 


Shutoff Valve, Solenoid W Manual OR 

27 


Quick Disconnect 

95 


3-Way Valve, Electrically Operated 

34 


Electric Heater 

20 


Pressure Regulator with Relief 

2 

2 

Pressure Control 

1 

1 

O 2 Sensor 

1 

1 

3-Way Valve, Pressure Actuated 

1 

1 

Shutoff Valve, Manual 

275 


Relief and Dump Valve 

2 

2 

Low Pressure Tank 

9 


Pressure Regulator 

5 


Compressor 

9 


Heat Exchanger, Liquid to Gas 

2 


Check Valve 

40 


Air Bypass Valve 

2 


Fan 

20 


Pump 

33 

7 

Condensing Heat Exchanger 

8 


Temperature Controller 

7 


Temperature Sensor 

8 


Adsorption Cannister 

19 


CO 2 Sensor 

8 
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Section 4 


CHECKOUT STRATEGIES 


4.1 SUBSYSTEM CHECKOUT STRATEGY 

Prior to any further requirements analysis, it is necessary to develop a 
checkout strategy for all Space Station subsystems to meet the checkout objectives 
of the Space Station OCS. The objectives of the Space Station OCS can be 
summarized as follows: 

o To increase crew and equipment safety by providing an immediate 
indication of out-of-tolerance conditions 

• To improve system availability and long-life subsystems assurancy 
by expediting maintenance tasks and increasing the probability 
that systems will function when needed 

• To provide flexibility to accommodate changes and growth in both 
hardware and software 

• To minimize development and operational risks 

Specific mission or vehicle-related objectives which can be imposed upon 
subsystem level equipment and subsystem responsibilities include the following: 

• OCS should be largely autonomous of ground control. 

• Crew participation in routine checkout functions should be minimized. 

i 

• The design should be modular in both hardware and software to 
accommodate growth and changes . 

• OCS should be integrated with, or have design commonality with, 
other onboard hardware or software . 

• The OCS should use a standard hardware interface with equipment 
under test to facilitate the transfer of data and to make the system 
responsive to changes. 

• Failures should be isolated to an LRU such that the faulty unit can be 
quickly removed and replaced with an operational unit. 
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• A caution and warning system should be provided to facilitate crew 
warning and automatic "safing" where required. 

• Provisions must be included to select and transmit any part or all of 
the OCS test data points to the ground. 

To attain these objectives via the use of an Onboard Checkout System which 
is integrated with the Data Management System, checkout strategies have been 
developed which are tailored to each Space Station subsystem. 

Special emphasis has been applied to a strategy for checkout of redundant 
elements peculiar to each subsystem. The degree to which each of these functions 
is integrated into the DMS is also addressed. 

4. 1. 1 SPACE STATION SUBSYSTEMS 

Each major Space Station subsystem was examined with respect to the re- 
quired checkout functions. The checkout functions associated with each subsystem 
are identified and analyzed as to their impact on the onboard checkout task. The 
functions considered are those necessary to verify operational status, detect and 
isolate faults, and to verify proper operation following fault correction. Specific 
functional requirements considered include stimulus generation, sensing, signal 
conditioning, limit checking, trend analysis, and fault isolation. 

The Structures Subsystem consists of the basic Space Station structure 
(shell, bulkheads, etc.) and the associated equipment such as meteoroid shields, 
hatches, airlocks, docking systems, antenna booms, and artificial gravity 
systems. 

4. 1. 1. 1 Checkout Functions 

Checkout functions associated with the Structures Subsystem are relatively 
few and simple. These are primarily related to the verification of compartment 
integrity, hatch and docking port status, and to the deployment of the high gain 
antennas and artificial gravity systems. The checkout task is characterized by 
low measurement data rates, absence of special test stimulus requirements, and 
by comparatively uncomplicated computation requirements. 

• Stimulus Generation - No stimuli, other than normal operational control 
signals, are required for checkout of the Structures Subsystem. 
Operational control requirements, as tabulated in Appendix I, consist 
of discrete commands for seal pressurization and similar functions. 
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• Sensing - Sensing requirements of the Structures Subsystem are almost 
entirely limited to measurement of mechanical parameters, such as 
door, latch and actuator position and to the measurement of gas pressure 
in compartments, seals, and associated tankage. These requirements 
are listed in Appendix I. 

• Signal Conditioning - A minimum of special signal conditioning is re- 
quired since many of the measurements, particularly the position 
measurements, are implemented in a manner (i. e. , with limit switches) 
which is directly compatible with the Data Acquisition System. Con- 
ditioning may be required for the pressure transducers, depending upon 
the type selected, and for the rotational sensor. Such conditioning, 
where required, performs conversion and scaling of the sensor outputs 
and provides a standard 0-5 Vdc output to the Data Management System. 

• Limit Checking - Periodic or continuous limit checking is required for 
selected pressure parameters, including seal pressures, compartment 
and airlock pressures, and docking ring compression strut pressures. 

• Trend Analysis - Analysis of the Structures Subsystem has revealed no 
potential application of long term trend analysis techniques. Short 
term analysis of compartment and seal pressures is required, however, 
to verify pressure integrity and to detect and isolate meteoroid punctures 
and other leaks. 

4. 1.1. 2 Redundant Element Checkout 

Redundancy in the Structures Subsystem takes the form of installed and 
independently active elements. A typical example is the dual seals on all pres- 
sure hatches. These redundant elements, being fully operational rather than of a 
standby nature and being independently instrumented and controlled, require no 
special treatment from the checkout standpoint. 

4. 1.1.3 Integration with Data Management Subsystem 

The checkout interface between the Structures Subsystem and the DMS con- 
sists of the measurement parameters listed in Appendix I of the Task 1 Final 
Report. All measurements at the interface are in the form of normalized 0-5 Vdc 
signals and are directly compatible with the Remote Data Acquisition Units. Test 
sequencing and control are provided by the DMS, as is operational control. 
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4. 2 INTEGRATED CHECKOUT STRATEGY 


This analysis identifies the integrated checkout functions associated with 
Space Station subsystems during the manned orbital phase of the mission. These 
functions are depicted in Figure 4-1 and are those required to ensure overall 
availability of the Space Station. Characteristic of integrated testing is the fact 
that the test involves subsystem interfaces, and, therefore, test objectives are 
associated with more than one subsystem. 

4. 2. 1 INTEGRATED CHECKOUT STRATEGY 

Six checkout functions have been identified: 

• Caution and warning 

• Fault detection 

• Trend analysis 

• Operational status 

• Periodic checkout 

• Fault isolation 

These functions represent a checkout strategy of continuous monitoring and 
periodic testing with eventual fault isolation to a line replaceable unit (LRU). 
Under this aspect the functions are grouped as - 

CONTINUOUS MONITORING PERIODIC TESTING FAULT ISOLATION 


• Caution and warning 

• Fault detection 

• Trend analysis 

• Operational status 


• Automatic tests 

• Operational 

Verification 


• Localize to SS 

• Isolate to RLU 
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Figure 4-1, Integrated Checkout Functional Flow 
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General characteristics of these groups are defined below: 

4. 2. 1. 1 Continuous Monitoring 

Continuous monitoring is not a test per se. It is a concept of continuously 
sampling and evaluating key subsystem parameters for in/out -of -tolerance con- 
ditions. This evaluation does not necessarily confirm that the subsystems have 
failed or are operating properly. The evaluation is only indicative of the general 
status of the subsystems. For example, a condition exists where the integrated sub- 
systems are indicating in-limit conditions, but during the next series of attitude con- 
trol commands, an error in Space Station position is sensed and displayed. The 
malfunction indication is only indicative of an out-of -tolerance condition of an 
integrated function. Final resolution of the problem to a subsystem and eventually 
to LRU will require diagnostic test procedures that are separate from the con- 
tinuous monitoring function. 


There are situations in which the parameters being monitored are intended 
to be directly indicative of the condition of a subsystem or an LRU. Examples of 
these include tank pressures, bearing temperatures, and power source voltages. 
However, even in these simpler cases when a malfunction is detected, an integrated 
evaluation will be performed to ascertain that external control functions, transducers, 
signal conditioning, and the DMS functions of data acquisition, transmission, and 
computation are performing properly. This evaluation will result in either a sub- 
stantiation of the malfunction or identification of a problem external to the param- 
eter being monitored. 

Figure 4-1 shows the logic associated with each function in the continuous 
monitoring group, as well as the integrated relationships between these and the 
total checkout functions. The caution/warning and fault detection functions are 
alike in their automatic test and malfunction detection approaches, but are differ- 
ent in terms of parameter criticality and malfunction reaction. The caution/warn- 
ing function monitors parameters that are indicative of conditions critical to crew 
or equipment safety. Parameters not meeting this criticality criteria are handled 
as fault detection functions. Figure 4-1 shows that in the event of a critical mal- 
function, automatic action is initiated to warn the crew and sequence the sub- 
systems to a safe condition. Before this automatic action is taken, the subsystems 
must be evaluated to ascertain that the failure indication is not a false alarm and 
that the corrective action can be implemented. After the action is taken, the sub- 
systems must be evaluated to determine that proper crew safety conditions exist. 

Since automatic failure detection and switching can be integral to subsystem de- 
sign (self-contained correction) and subsystems can be controlled by the operation- 
al software or manual controls, it is imperative that the status of these events be 
maintained and that the fault detection and correction software be interfaced with 
the prime controlling software. For malfunctions that are not critical, the crew 
is notified of their occurrence, but any subsequent action is initiated manually. 
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The next continuous monitoring function, trend analysis, automatically ac- 
quires data and analyzes the historical pattern to determine signal drift and the 
need for unscheduled calibration. It also predicts faults and indicates the need 
for diagnostic and fault isolation activities. An example of a parameter in this 
category is the partial pressure of nitrogen. Nitrogen is used to establish the 
proper total pressure of the Space Station. Since it is an inert gas, the only make- 
up requirements are those demanded by leakage or airlock operation. The actual 
nitrogen flow rate is measured, and calculations are performed which make 
allowances for normal leakage and operational use. When these calculations 
indicate a trend toward more than anticipated use, the crew is automatically 
notified and testing is initiated to isolate the problem to the gas storage and 
control equipment or to an excessive leak path. The historical data is not only 
useful in predicting conditions but is also useful in providing trouble-shooting clues. 
The data might reveal, for example, that the makeup rate increased significantly 
after the use of an airlock. This could lead directly to verifying excessive seal 
leakage. 

The final continuous monitor function is in operational status. This function 
is performed by the crew and is nonautomatic with 'the exception of the DMS com- 
puter programs associated with normal Space Station operational control and 
display functions. The concept of continuous monitoring recognized and takes 
advantage of the crew's presence and judgment in evaluating Space Station per- 
formance. In many instances the crew can discern between acceptable and un- 
acceptable performance, and they can clearly recognize physically-damaged 
equipment or abnormal conditions. 

4. 2. 1.2 Periodic Testing 

As opposed to continuous monitoring, periodic testing is a detailed evalua- 
tion of how well the Space Station subsystems are performing. Figure 4-1 shows 
that periodic testing is not accomplished by any one technique. Rather, a com- 
bination of operational and automatic test approaches is employed. The actual 
operational use of equipment is often the best check of the performance of that 
equipment. Operation of Space Station equipment and use of the normal operating 
controls and displays will be used in detecting faults and degradation in the sub- 
systems. This mode of testing is primarily limited to that equipment whose 
performance characteristics are easily discernible, such as for motors, lighting 
circuits, and alarm functions. 

Automatic testing is performed in two basic modes: 

• With the subsystems in an operating mode, the DMS executes a diagnos- 
tic test procedure which verifies that integrated Space Station functions 
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are being properly performed under normal interface conditions in 
response to natural or designed stimulation. This mode of testing 
allows the evaluation of Space Station performance without interrupting 
mission operations. 

• For those situations where the integrated performance or interface 
compatibility between subsystems cannot be determined without known 
references or control conditions, the DMS will execute a diagnostic 
procedure in a test mode. In this mode, control, reference, or bias 
signals will be switched in or superimposed on the subsystems to allow 
an exact determination of their performance or localization of problem 
between the interfaces. Since the test mode may temporarily inhibit 
normal operations, the DMS must interleave the test and operational 
software to maintain the Space Station in a known and safe configuration. 

The scheduled automatic tests are performed to verify availability or proper 
configuration of "on-line" subsystems, redundant equipment, and alternate modes. 

• Periodic Verification of "On-Line" Subsystems - The first checkout 
requirement is a periodic verification that on-line subsystems are 
operating within acceptable performance margins. The acceptable 
criteria for this evaluation is based on subsystem parameter limits and 
characteristics exhibited during Space Station factory acceptance or 
pre-flight testing. The rejection criteria and subsequent decision to 
repair or reconfigure subsystems is based on the criticality of the 
failure mode. If the subsystems appear to be operating properly, but 
the test clearly indicates an out-of-tolerance condition, then one of the 
following alternatives must be implemented: 

If the failure mode is critical, the crew normally takes immediate 
action to isolate and clear the problem. 

If the failure mode is not critical, the crew can take immediate 
action, schedule the work at a later time, or wait until the condi- 
tion degrades to an unacceptable level. 

• Redundant Equipment Verification - A second checkout requirement is 
verifying that standby, off-line, or redundant equipment and associated 
control and switching mechanisms are operable. The acceptable/re- 
jection criteria for these evaluations is identical to those for normally 
operating equipment. A primary distinction of this function is that 
equipment may have known failures from previous usage or tests. This 
situation occurs when the crew has knowledge of a failure but has not 
elected to perform the necessary corrective action. The checkout 
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function then becomes one of equipment status accounting and main- 
tenance/repair scheduling. The status information is interlocked with 
mission procedures and software to preclude activation of failed units 
while they are being repaired or until proper operation following repair 
is verified. 

• Alternate Mode Verification - The third checkout function is verifying the 
availability of alternate modes of operation. This function is essentially 
a confidence check of the compatibility of subsystems’interaction and 
performance during and after a change in the operating mode. To some 
extent this function overlaps with redundant equipment verification, but 
is broader in scope in that it verifies other system-operating character- 
istics. For example, some modes will involve manual override or 
control of automatic functions or automatic power-down sequences. 

4. 2.1.3 Fault Isolation 

Fault isolation to an LRU is a Space Station goal. As shown in Figure 4-1, 
fault isolation testing is initiated when malfunction indications cannot be directly 
related to a failed LRU. The integrated test functions associated with fault isola- 
tion are localizing a malfunction to a subsystem or to an explicit interface between 
two subsystems and identifying the subroutine test necessary for LRU isolation. 

In structuring this relationship between integrated subsystem tests for fault local- 
ization and subroutine tests for fault isolation, the DMS, in conjunction with the 
test procedure documentation, must establish an effective man- machine interface 
so that in the event of an unsolved malfunction the crew will be able to help evalu- 
ate the condition and determine other test sequences necessary to isolate the 
problem. To accomplish this requirement, the DMS must be capable of displaying 
test parameters and instructions in engineering units and language and be capable 
of referencing these outputs to applicable documentation or programs that correl- 
ate test results to corrective action required by the crew. 
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Section 5 


ONBOARD CHECKOUT TEST DEFINITIONS 
5. 1 SUBSYSTEM TEST DEFINITIONS 


The on-orbit tests required to insure the availability of the Space Station 
subsystems are defined herein. Also delineated are the measurement and 
stimulus parameters required to perform these tests. Two discrete levels of 
testing are defined, i. e. , continuous status monitoring tests for fault detection of 
critical and noncritical parameters, and subsystem fault isolation tests for 
localization of faults to a specific Line Replaceable Unit. In addition to these two 
levels, tests are defined for periodic checkout and calibration of certain units, 
and parameters requiring analysis of trends are defined. 

Due to the software module approach to DMS checkout, it was deemed 
necessary to estimate the CPU time and memory required to implement these 
modules along with an assessment of the services required from an Executive 
Software System to control the checkout. 

These test descriptions, measurement, and stimulus information provided 
for each subsystem, and the software sizing information provided for the Data 
Management System provide the data required to estimate the checkout impact 
on the DMS software and hardware. Table 5-1 is a summary of the measurement 
and stimulus requirements for the Space Station. 

The Structural Subsystem forms and maintains the compartment divisions of 
the Space Station. It provides a pressure shell/structural shield designed for high 
damage resistance from external projectiles (meteorites), and eliminates stresses 
due to orbital thermal cycling. 

Ports are provided on the exterior structure shell to accommodate docking 
of resupply/logistic and experiment modules which enhance orbital life and 
versatility of the basic station design. 

The Structures Subsystem also includes provisions needed for deployment of 
the spent S-II stage as a counterweight for the artificial gravity mode of operation. 

Operational assessment of the Structures Subsystem elements is generally 
accomplished by monitoring of measured system parameters, and to a significant 
extent, by visual' inspection. Operational measurements for the subsystem are 
predominantly of the event monitoring type intended to inform the crew of the 
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immediate configuration/status of the subsystem. Functions to be monitored and 
displayed included position/event data on docking rings, hatches and airlock doors, 
and antenna booms. Analog measurements/display include counterweight position 
and pressures, temperatures, and power monitoring of compartment divisions and 
functional units which provide pre and post event data to the crew for condition 
assessment. It should be noted that the operational data requirements for this 
subsystem are extremely event-oriented and that the frequency of use is low 
(ave 1/mo). Hence, the impact upon the Data Management Subsystem for real-time 
continuous data display and computation is also minimal (e. g. data callup in lieu of 
full-time dedication is acceptable). Measurement and stimuli requirements for the 
Structures Subsystem are contained in Appendix 1-6 of the Task 1 Final Report. 

5. 1. 1 STATUS MONITORING 

Due to the nature of the Structures Subsystem the requirements for continuous 
status monitoring for purposes of fault detection are quite limited. Such monitoring 
requirements that do exist utilize selected operational status parameters such as 
temperature and pressures. Required sampling rates are relatively low and are 
not critical. Acceptance rejection criteria are based upon comparison of measured 
values with predetermined limits. Support from the EC/LS Subsystem monitor of 
atmosphere consumption is utilized for detection of abnormal compartment leakage. 
Detection of out-of-limit conditions results in notification of the crew. Since no 
safety critical functions are involved, no automatic corrective action is required. 
Fault isolation is accomplished by combined crew/automatic procedures. Auto- 
matic fault detection is heavily supplemented by crew observation of normal sub- 
system status displays and of the actual equipment during operation. 

No caution/warning functions have been identified in association with the 
Structures Subsystem. Certain related functions such as hull leaks are covered by 
EC/LS caution/wafning functions. 

5. 1. 2 TREND ANALYSIS 

No trend analysis requirements have been identified for this subsystem. 

5.1.3 PERIODIC CHECKOUT AND CALIBRATION 

Periodic checkout of the Structures Subsystem elements is planned to occur 
either prior to a scheduled event such as module docking and artifical-g deployment/ 
termination or -during specific operational times such as shift changes where status 
information pertaining to compartment configuration (hatch positions) and antenna 
positions is of interest to the oncoming crew. 
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Functional checkout of the docking mechanism, which includes visual inspec- 
tion and extension/retraction of the docking ring is conducted prior to a scheduled 
docking event to verify operation of the mechanism before committing the arriving 
module to that port location. This checkout is scheduled sufficiently in advance to 
permit reassignment of the module in the event of malfunction. Likewise, periodic 
start-of-shift checks of the station configuration are planned to alert the oncoming 
crew as to overall subsystem status. 

Periodic review of EC/LS atmosphere consumption trend analysis is also 
planned to assess leakage of the pressurized compartment(s) to establish "as is" 
acceptance or need for corrective action. 

5.1.4 FAULT ISOLATION 

The fault isolation process to the LRU level for the Structures Subsystem 
lacks the complexity generally associated with electronic subsystems due to the 
nature of the hardware elements involved. In most instances malfunctions are 
obvious from the operational data being displayed or by visual inspection, and 
therefore require a minimum of DMS support. Isolation of leaks in the pressure 
shell of the station will utilize a combination of pressure decay, visual inspection, 
and sonic detector techniques. Pressure decay tests, accompanied by acoustical 
leak sensors on the shell surface, will permit isolation to a specific compartment/ 
location. If the leakage occurs in association with an event such as EVA or docking 
visual inspection for seal/structural damage of the hatch/door involved will be 
utilized. Scuffing, wear, or puncture of a seal will be suspect. Isolation of leaks 
in the basic structure shell will utilize the ultrasonic detection technique which 
employs the use of portable detectors capable of sensing ultrasonic energy in the 
frequency range of 35-50 KHz produced by gas flow through an orifice. 

5.2 INTEGRATED TEST DEFINITION 

The task of ensuring overall Space Station availability is primarily dependent 
upon the proper structuring of individual subsystem tests. The ability to test the 
subsystems independent of other subsystems is directly related to the number and 
types of interfaces. As shown in Figure 5-1, the DMS and Electrical Power Sub- 
systems (EPS) interface with every other Space Station subsystem. In addition, 
the EC/LS Subsystem provides cooling to most of the electronic packages. 
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This situation demands that in constructing the test for a subsystem these inter- 
faces be taken into account so that erroneous or ambiguous test results will not 
be obtained. In other words, before detailed subsystem fault isolation tests are 
initiated, a higher level of testing should be performed to verify that all interfaces 
and Space Station conditions that influence the subsystem are proper. Properly 
designed, these higher-level tests will (1) indicate what Space Station conditions 
must be verified, maintained, or changed; (2) localize the malfunction to a single 
subsystem; and (3) identify the subroutine test necessary for fault isolation. 

Since the DMS interfaces with all of the Space Station subsystems and is 
used as the OCS, it would appear that all of the tests would be integrated. How- 
ever, this is not a proper interpretation. When the DMS is used to verify the 
performance of another subsystem, it must first establish itself as a test standard 
against which the subsystem parameters are compared. Subsequent to this veri- 
fication, the test is dedicated to the evaluation of the subsystem. This test would 
be considered as an independent test since the objective of the test was to verify 
the subsystem and not the DMS. For a test to be considered as an integrated test 
it must meet one or more of the following conditions: 

• Test objectives associated with more than one subsystem 

• Test involves subsystem interfaces 

• Test requires proper operation of other subsystems 

In several cases, the DMS must simultaneously perform the dual role of 
OCS and functional elements. As an example, the DMS has a functional interface 
with the GN&C and Prop Subsystems for the computation of guidance equations and 
the execution of commands to the control actuators. When this functional closed 
loop is being tested, the DMS must, in addition to performing its normal functions, 
execute the test routine. For this type of integrated test there must be an intrinsic 
relationship between the operational and test software. This relationship must be 
carefully considered in structuring the integrated tests since unstable or inter- 
mittent performance may be detected only in the exact operating mode under 
closed-loop conditions. The number of integrated tests is not extensive due to the 
approach of minimizing the different types of interfaces between Space Station sub- 
systems. For example, interfaces between the DMS and other subsystems are 
largely standardized. As a result, relatively common tests can be designed for 
verification of the multitude of DMS subsystem interfaces or for localization of a 
fault to one side of a DMS subsystem interface. 
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This situation demands that in constructing the test for a subsystem these inter- 
faces be taken into account so that erroneous or ambiguous test results will not 
be obtained. In other words, before detailed subsystem fault isolation tests are 
initiated, a higher level of testing should be performed to verify that all interfaces 
and Space Station conditions that influence the subsystem are proper. Properly 
designed, these higher-level tests will (1) indicate what Space Station conditions 
must be verified, maintained, or changed; (2) localize the malfunction to a single 
subsystem; and (3) identify the subroutine test necessary for fault isolation. 

Since the DMS interfaces with all of the Space Station subsystems and is 
used as the OCS, it would appear that all of the tests would be integrated. How- 
ever, this is not a proper interpretation. When the DMS is used to verify the 
performance of another subsystem, it must first establish itself as a test standard 
against which the subsystem parameters are compared. Subsequent to this veri- 
fication, the test is dedicated to the evaluation of the subsystem. This test would 
be considered as an independent test since the objective of the test was to verify 
the subsystem and not the DMS. For a test to be considered as an integrated test 
it must meet one or more of the. following conditions: 

• Test objectives associated with more than one subsystem 

• Test involves subsystem interfaces 

• Test requires proper operation of other subsystems 

In several cases, the DMS must simultaneously perform the dual role of 
OCS and functional elements. As an example, the DMS has a functional interface 
with the GN&C and Prop Subsystems for the computation of guidance equations and 
the execution of commands to the control actuators. When this functional closed 
loop is being tested, the DMS must, in addition to performing its normal functions, 
execute the test routine. For this type of integrated test there must be an intrinsic 
relationship between the operational and test software. This relationship must be 
carefully considered in structuring the integrated tests since unstable or inter- 
mittent performance may be detected only in the exact operating mode under 
closed-loop conditions. The number of integrated tests is not extensive due to the 
approach of minimizing the different types of interfaces between Space Station sub- 
systems. For example, interfaces between the DMS and other subsystems are 
largely standardized. As a result, relatively common tests can be designed for 
verification of the multitude of DMS subsystem interfaces or for localization of a 
fault to one side of a DMS subsystem interface. All special integrated tests that 
have been identified are discussed in the following paragraphs. The GN&C/DMS/ 
PROP configuration for navigation and attitude control poses the most difficult 
problem for on-orbit testing so it is presented in significant detail. Other inte- 
grated tests are summarized. 
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5.2.1 EC/LS - EPS ISOTOP E/BRAYTON INTERFACE 

The Environmental Control/Life Support (EC/LS) Subsystem interfaces with 
the EPS Isotope/Brayton System for removal of waste heat via a fluid heat ex- 
changer installed in the Brayton Power Conversion System. It is planned that flow 
rate, temperature, and pressure parameters be continuously monitored on both 
sides of the interface as part of normal EPS and EC/LS Subsystem checks. 

5.2.2 EC/LS - LOW-THRUST PROPULSION INTERFACES 

The EC/LS Subsystem interfaces the low-thrust portion of the Propulsion 
Subsystem to supply unreacted CO 2 from the CO 2 removal assembly, methane by- 
products from the CO 2 conversion assembly, and excess water. The Propulsion 
Subsystem uses these biowaste fluids in the Low-Thrust System as propellant. 

The interface is controlled by the DMS or by manual control to satisfy such para- 
meters as propellant and pressurant selection. These parameters are primarily 
a function of impulse requirements and available stores. Checkout of the interface 
is required to verify proper valve and pump operation for the transfer of the waste 
gases and excess water. 
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Section 6 


SOFTWARE 


6.1 GENERAL CONSIDERATIONS 

The recommended software checkout startegy involves a sequence of 
detecting faults, isolating faults to a failing LRU or LRUs, and reconfiguring the 
system to continue operation while the failures are being repaired. 

This recommendation was developed by evaluating each subsystem with 
respect to the three general requirements of fault detection, fault isolation, and 
reconfiguration. 

Fault detection incorporates both the recognition of failure occurrence, and 
the prediction of when a failure can be expected to occur. The Remote Data 
Acquisition Units (RDAUs) continually check selected test point measurements 
against upper and lower limits, and notify the executive on an exception basis when 
a limit is exceeded. This approach avoids occupying the central multi-processor 
with the low-information task of verifying that measurements are within limits. 

Trend analysis is a fault detection technique recommended for predicting the 
time frame during which a failure can be anticipated. Data is acquired on a basis 
of time or utilization, and compared with previous history to determine if a ’'trend" 
toward degraded performance or impending failure can be detected. 

Another checkout requirement evaluated for each subsystem is periodic 
testing. This type of test is provided to exercise specific components at extended 
time intervals or prior to specific events, to assure operational integrity. In the 
event that a failure is detected, the periodic test will isolate to the failing Line 
Replaceable Unit (LRU) and accomplish recertification after a repair operation. 

Calibration of specific subsystem components will be required periodically, 
or subsequent to a repair and/or replace operation. The techniques involved are 
unique to the individual component; and, in some cases, require the acquisition of 
operational data. 

Fault isolation is required when a fault is detected. When a particular fault’ 
provides an indication that a life critical failure has occurred, the fault isolation 
routines are automatically initiated. If the failure does not represent an immediate 
danger to the vehicle occupants, the crew is notified and they will initiate the fault 
isolation modules at their convenience. 
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The basic requirements of the fault isolation function is to analyze the avail- 
able information relevant to a problem, and identify the LRU which is responsible 
for the anomaly. 

Three basic approaches to meeting this requirement were considered. These 

are: 

• Analyze each fault as an independent problem 

• Analyze each fault with a state matrix which defines the possible error 
states of the subsystem 

• Associate each fault with a specific subsystem, and evaluate that 
subsystem in detail 

The third approach was selected on a basis of software commonality and cost 
effectiveness. The complexity associated with the testing can be reduced by locali- 
zation of the logic associated with the analysis of the subsystem in a unique package. 
The software commonality will result in reduced software development and main- 
tenance costs, while increasing the reliability of the software. 

The fault isolation software is structured modularly for compatibility with 
the hardware structure of the subsystem. Checkout modules evaluate the per- 
formance of a specific portion of the subsystem. A convenient division for this 
modular structure is at the assembly level or functional area. A program module 
which can determine and control the sequence in which these checkout modules are 
executed is also required for each subsystem. 

Subsequent to fault detection, the software associated with the subsystem 
which is most likely to contain the error will be activated. 

The subsystem software will analyze the error indication, and initiate a 
sequence of checkout modules to isolate the problem. If successful, the crew is 
notified regarding the Line Replaceable Unit (LRU) to be replaced. If an error 
cannot be identified, the crew is informed of the situation and has an option to 
execute the periodic test of the subsystem. 

After a fault has been isolated, reconfiguration software restores the 
functional capability of the subsystem. This is most commonly accomplished by 
exchanging a redundant element for the failing unit, or by defining an alternate 
path to accomplish the required function. 

The Task 2 Final Report of the basic onboard checkout techniques study 
provides descriptions of the software requirements, definitions and design in 
addition to detailed flow charts of specific checkout routines. 
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6. 2 SPACE STATION SUBSYSTEM 


The basic Space Station structure provides the necessary pressurized 
habitat, equipment support, meteoroid protection, radiators, insulation, and 
docking interfaces to meet operational requirements. 

The fault detection function required for the Structures Subsystem is accom- 
plished by tables which are monitored by the OCS executive program. The tables 
contain the parameters which must be monitored to assure subsystem perfor- 
mance. These tables are transferred to the Remote Data Acquisition Unit (RDAU) 
via the master executive program, and limit checking is accomplished. Figure 6-1 
provides a graphic description of this function. 

The program described by this document is required for periodic checkout 
and fault isolation. 

Initiation of the periodic checkout function is accomplished as the result of 
a keyboard entry by a crew member. It is anticipated that periodic checkout will 
be accomplished prior to a scheduled event such as docking, artificial "G" deploy- 
ment, or during specific operational times such as shift changes where status 
information pertaining to hatch and docking port positions are of interest to the 
on-coming crew. 

The fault isolation utilizes the same software modules as the periodic 
checkout; however, it is anticipated that analysis of the detected error will permit 
selection of the appropriate module to begin the required fault isolation. 

This program meets the periodic testing and fault isolation requirements for 
the Structure Subsystem. 

Four specific functional areas of the subsystem require automated checkout. 
They are: 

• Docking Mechanisms 

• Antenna Deployment Mechanisms 

• Basic Structure 

Spacecraft Access 

Hatches 

Hangar 

B/l Power System Handling 

• Artificial "G" Considerations 
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Figure 6-1. Fault Detection Logic 
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Figure 6-2 provides a block diagram of the functional areas of this subsystem. 

The varied requirements of program execution are met by providing the oper- 
tor with the capability to select specific options of the program. 

The operation of the options of this program is depicted in Table 6-2. These 
options include the capability to provide the current operational status, docking 
mechanism checkout, antenna operations checkout, and to check out the provision 
included for an artificial "G" environment. 

6. 2. 1 SYSTEM REQUIREMENTS 

This section describes system constraints and requirements which have 
influenced design. 

6. 2.1.1 Subsystem Definition 

This program specification is based upon the subsystem definition which is 
available as a result of this study contract. The test points for this subsystem are 
currently defined at the assembly level; and consequently every failure which is 
detected cannot be identified with a special LRU (Refer to Table 6-1). 

6. 2. 1.2 Docking Mechanism Checkout Module 

There is no test point available to extend or retract the docking ring. The 
existence of a test point labeled "Docking Ring Pressure Control” has been 
assumed. This stimuli will permit extension and retraction of the docking ring. 

6. 2. 1.3 Artificial "G" Checkout Module 

The periodic and fault isolation test requirements indicated in the measure- 
ment and stimulus list include test points labeled "Cable Deployment Drum Travel. " 
The information supplied by these test points can only be evaluated during an actual 
deployment. Consequently, these test points have been omitted for periodic and 
fault isolation testing. It is anticipated that additional test points will be identified 
in the future to assure the continuity of these measurements. 

There are controls provided in the system for the Operation of the S-II 
latches. These latches are used to hold the S-II stage and are released during the 
deployment sequence. Because of the problems that could occur if the latches 
failed to relock during a test, these components are not exercised as a function of 
the periodic or fault isolation test. 
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Figure 6-2. Structure Subsystem Functional Areas 


STRUCTURES 

SUBSYSTEM 


DOCKING 


BASIC 


ARTIFICIAL 

MECHANISMS 


STRUCTURE 


GRAVITY 





CONSIDERATIONS 


• DOCKING COVER 


• SPACECRAFT ACCESS 


• DOCKING RING 

• DOCKING SEAL 


- HANGER 

- HATCHES 

• BA- POWER SYSTEM 
HANDLING 


ANTENNA 

DEPLOYMENT 


• STOWED 

• MAINTENANCE 

• EXTENDED 




Table 6-1. LRU Identification 


This table includes a list of LRU types which make up the structures subsystem. 
Those which can be associated with specific test points are indicated by asterisks. 

Table 3-1. LRU Identification 


Line Replaceable Unit 

Identifiable 

Docking Mechanism Shock Struts 

* 

Docking Port Inflatable Seals 

* 

Hatches and Airlock Doors Inflatable Seals 


Inflatable Airlock 


Viewport Window Assembly 


Hatch Temperature Indicators 


Hatch Pressure Indicators 


Hatch Assembly 

* 

Despin Module Drive Unit 

* 

Cable Deployment Module Drive 


Docking Port Seal Latches 


Antenna Boom 


Antenna Boom Drive Unit 

* 

Cargo Handling Hoist 


Cargo Hoist Cable 


Electric Drive Unit, Isotope System Handling 

* 

Handling Aids, Isotope System 



The checkout of the design module requires limit checking on the basis of 
operational information to be acquired from the operational system. Lack of 
definition regarding specific data and algorithms prevents consideration of this 
requirement in the software analysis. 

6.2. 1.4 Allocable Equipment 

The checkout which this program must accomplish requires that the following 
components be indepently identifiable, and dedicated to this program for a specific 
time interval. 


Docking Ports 

Hangar 

Hatches 


Antennas 

De-spin Module 

Cable Deployment Module 




6.2.2 OPERATIONAL REQUIREMENTS 


This program specification defines specific operational requirements for 
periodic testing and fault isolation of the following areas: 

• Docking Mechanism 

• Hatches, Airlocks, and Viewports 

• Artificial Gravity Experiment Provisions 

• Antenna Deployment 

• Isotope Power System Handling and Replacement Equipment 

The specific program modules which meet these requirements are: 

• Option selection 

• Operational status 

• Docking mechanism checkout 

• Spacecraft access module 

• Antenna fault isolation 

• Isotope/Brayton power handling 

• Artificial "G" checkout 

A module block diagram of the program is provided in Figure 6-3. 

6.2.2. 1 Option Selection 

This function processes the selection of options to permit the selective 
checkout of specific functional areas. The options selected will be determined 
from the parameter data supplied to the program. These options are defined in 
Table 6-2. The outputs of the option selection are used by the program to select 
the proper options for execution. Tutorial displays are also required. 

The information processing program module processes the input parameter 
information, and executes the program module specified by the options defined in 
Table 6-2. 

The parameter information passed to the program will be examined. If none 
was included, the program will execute the programmed default option of checking 
the operational status of specific test points. (Refer to paragraph 6. 2. 2. 2. ) 
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Figure 6-3. Structures Subsystem Checkout Program Modular Block Diagram 
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Table 6-2. Initial Program Options 


Keyword 

- 

Program Response 

STATUS 

- 

Execute the Operational test point status module 

DOCK 

- 

Execute the Docking mechanism checkout module 

ANTENNA 

- 

Execute the Antenna Fault Isolation module 

SPAC 

- 

Execute the Spacecraft access checkout module 

OPTN 

- 

Display Options 

IBP 

- 

Execute the Isotope/ Bray ton Power handling module 

ATRG 

- 

Execute Artificial G checkout module 

FI 

- 

Execute fault isolation routines in addition to 
periodic check. 


If the keyword OPTN is included in the parameter data, the program displays 
the available options and waits for the operator to enter his selection. 

Any combination of keywords may be entered; however, they must be 
separated by a comma. The introduction of a blank character will be used to 
terminate the input string. 

As the keywords are identified, an associated flag is set to indicate the 
function to be accomplished. The program will then examine each flag and trans- 
fer control to the appropriate module for execution. 

6. 2. 2. 2 Operational Status 

This module is executed to provide the crew with information relating to 
the current status of the docking ports, hatches, and hangar door positions. 
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The inputs for this function are obtained from the data base table which the 
executive monitors to keep track of the status of various system components. This 
information is based on data received from the following test points: 

• Docking Ring Position - This test point indicates if the docking ring is 
extended or retracted. 

• Docking Port Cover Position - This test point indicates if the docking 
port cover is open or closed. 

• Hatch Position Open/Close - Two measurements are required for each 
hatch to determine if it is opened or closed. One test point indicates 
the hatch is open, the other indicates the hatch is closed. 

• Hangar Door Position Open/Close - Two measurements are required to 
determine if the hangar is opened or closed. One test point indicates 
an open status; the other a closed status. 

The status of the test points identified in Table 6-3 are displayed on the 
display console. 

The information processing routine accesses the data base to determine the 
positions of the docking ring, the docking port cover, the hatches, and hangar 
door. This information is displayed at the console which requires execution of 
the program. 

Table 6-3. Operational Status Test Points 


FUNCTIONAL AREA 

STATUS TEST POINTS 

DOCKING MECHANISM 

DOCKING RING POSITION 
DOCKING PORT COVER POSITION 

SPACECRAFT ACCESS 

HATCH POSITION 
HANGER DOOR POSITION 
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6. 2. 2. 3 Docking Mechanism Checkout 

The periodic and fault isolation test requirements for the docking mechanism 
are identical. This routine is executed to assure the operational status of the 
docking mechanism. 

The primary inputs for this function consist of the subsystem test point 

data. 


Specific test points are: 

• Docking Port Seal Pressure - The two analog pressures associated with 
docking port seals are examined to assure that they are within established 
limits . 

• Docking Port Cover Position - This binary test point is used to deter- 
mine the position of the docking port cover (open/closed). 

• Docking Port Cover Control - This test point is used to command the 
docking port cover to the open or closed position. 

• Docking Ring Pressure Control - This test point is used to extend or 
retract the docking ring. 

• Docking Ring Position Extended/Retracted - There are two test points 
for each docking port. One signal indicates an extended position while 
the other signal indicates that the docking ring is retracted. 

• Docking Ring Strut Pressure - When the docking ring is extended, this 
test point is examined to determine whether the strut pressure is within 
limits. 

Additional inputs are received as a result of the operator's response to the 
GO- NO GO options. 

An output descriptive message relative to test points, which indicates an 
apparent error condition, is presented on the display console. When possible, 
the associated LRU is also identified. 

The information processing routine uses a subroutine to check the docking 
seal pressure at each docking port. The program then attempts to allocate a 
docking port to prevent altering one of the mechanisms which may be functioning 
in an operational status. The program then extends and retracts the docking port 
ring. Each ring is left in its initial position. All position information which is 
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obtained from test points is checked by comparison with the current status being 
maintained in the data base. For each error that is detected, a failure is indicated 
for the component, and the operator is presented with an appropriate display. 

6. 2. 2. 4 Spacecraft Access Control 

This function is used to check the operational status of the spacecraft hatches 
and hangar door, for both fault isolation and periodic testing requirements. 

The inputs for this function consist of the subsystem test point data. Specific 
test points are: 

• Hangar Door Position Open/Close - There are two points for the hangar 
door. One indicates the open position; the other a closed status. 

• Hangar Door Control - This, stimuli is used to open and close the hangar 
door. 

• Hangar Pressure - There are two stimuli points for the measurement of 
the pressure inside the hangar. 

• Hangar Temperature - There are two analog points available to measure 
the temperature inside the hangar. 

• Hatch Position Open/Close - There are two stimuli for each of the 16 
hatches. One signal indicates the open position; while the other indicates 
the closed position. 

An output descriptive message relative to test points which indicate an appar- 
ent error condition are presented on the display console. When possible, the 
associated LRU is also identified. 

In order to efficiently achieve the requirements for both periodic testing and 
fault isolation for the spacecraft access components, the two were combined into 
one module and execution is at the operator’s option. 

The program assures that both test points which provide hangar door positions 
are in agreement with each other, and with the status being maintained by the DMS. 
If disagreement is detected, the operator is provided with an appropriate display. 
When the points and status are in agreement, the hangar door is moved through 
both the open and closed positions; and the test points and DMS are again examined 
for consistency. The operator is notified by a display if the door fails to operate, 
or the positional indicators provide conflicting information. 
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Subsequent to verifying the hangar door operation if the fault isolation option 
has been selected, the temperature and pressure in the hangar are limit checked. 

In the event of a failure, the hangar is configured non -ope rational and the operator 
is notified by a display. 

The test points which indicate hatch positions are compared against each 
other and with the DMS status to assure compatibility. In the event of a dis- 
crepancy, the hatch will be configured non-operational and the operator is notified 
by a display. 

For each error that is detected, a failure is indicated for the component; 
and the operator is presented with the appropriate display. 

6. 2. 2. 5 Antenna Fault Isolation 

The program requires the capacity to analyze the antenna system for purposes 
of fault isolation. 

The inputs for this function consist of the subsystem test point data. Specific 
test points are: 

• Boom Position - This point is used to determine if the antenna is stowed, 
extended, or retracted for maintenance. 

• Launch Storage Position Lock Status - This test point is used to deter- 
mine the lock position when the antenna is stowed. 

• Antenna Launch Stowage Lock Control - This test point is used to assure 
that the stowage lock can be locked and unlocked to permit deployment 
of the antenna. 

• Boom Deployment Position Lock Status - This test point is used to 
determine the boom lock status when the boom is extended. 

• Boom Deployment Lock Control - This test point is used to assure that 
the boom locks can be locked and unlocked when the boom is extended. 

• Boom Maintenance Position Lock Status - This test point is used to 
determine the boom lock status when the boom is in the maintenance 
position. 

• Boom Maintenance Position Lock Control - This test point is used to 
lock and unlock the boom while it is in a maintenance position. 
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• Drive Unit Power Monitor - This test point is used to be sure that the 
power monitor is operating within limits. 

• Drive Unit Control - This test point is used to issue a test level to the 
drive unit power monitor, which is then limit checked. 

An output descriptive message relative to test points which indicate an 
apparent error condition are presented on the display console. When possible, 
the associated LRU is also identified. 

The information processing program module performs fault isolation for 
each antenna. The boom position is read from the specified test point and com- 
pared with the current position being maintained by the Data Management System, 
to insure compatibility. The antenna is in a stowed, extended, or maintenance 
position. The lock, which is associated with that position, is then checked and 
again compared with the Data Management System's records for it. If everything 
is in agreement, the lock is unlocked and relocked to be sure of its operational 
capacity. 

Any discrepancy between positions or failure to lock or unlock results in a 
message being provided to the operator. 

The drive unit power monitor is then limit checked as the final part of this 
module operation. 

For each error which is detected, a failure is indicated for the component; 
and the operator is presented with the appropriate display. 

6. 2. 2. 6 Isotope/Brayton Power Handling Module 

This program module is required to check the Isotope/Brayton power 
supply for purposes of fault isolation. The inputs for this function are the test 
point values for the power. A descriptive message relative to the power test 
point is presented on the display console when an error is indicated. The 
information processing module performs fault isolation by limit checking the 
drive unit power monitor for the Isotope/Brayton power supply. 

6.2.2. 7 Artificial "G" Checkout Module 

This program module is used to check out the considerations in the structures 
for the artificial "G” environment. It is anticipated that it will be executed prior 
to both spin up and spin down activities. 
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The inputs for this function consist of the subsystem test point data. Specific 
test points are: 

• Spoke Pressure Supply - This test point is used to assure that the 
pressure supply for the spoke is within limits. 

• Spoke Internal Pressure - This test point is used to assure that the 
internal pressure within the spoke is within limits. 

• De-spin Module Rotation Control - This test point is used to place the 
de-spin module in rotation. 

• De-spin Module Rate - This test point is used to measure the rate of 
the de-spin module's rotation. 

• De-spin Module Power - This test point is used to assure that the power 
being supplied to the de-spin module is within limits. 

• S-II Stage Latches Latched/Unlatched - Two test points are used to 
ascertain the status of the S-II stage latches. 

• Cable Deployment Module Strut Ring Position - This test point is used 
to determine the strut position. In a zero "G" environment, it should 
be retracted. In an artificial "G" environment, it should be extended. 

• Cable Deployment Module Power Monitor - This test point is examined 
to be sure that the module power monitor is within limits. 

An output descriptive message relative to test points, which indicate an 
apparent error condition, is presented on the display console. When possible, the 
associated LRU is also identified. 

The information processing program module is used to accomplish periodic 
checkout and fault isolation of those components associated with the artificial "G" 
environment. The internal pressure supply for the spoke and the internal pressure 
in the spoke are tolerance checked to assure the habitability for the crew in the 
spoke. The program then limit checks the power to the de-spin module to assure 
it is within limits. A de-spin module rotational command is issued to the de-spin 
module. This command is based upon access to operational data which provides 
the spin rate of the space station. Using this data, rates are computed which the 
module is expected to attain. The de-spin module rate is evaluated at one second 
intervals for a sample period and compared to the precalculated limits. 

Status checks are then made on the cable deployment module. The S-II latch 
positions are status checked; and in the event of a positional discrepancy, the dis- 
play reflecting the S-II latch positions is presented. The strut position is then 
status checked to assure that it is in the proper position for the current environment. 
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6. 2. 2. 8 Termination Routine 


This module is included to assure the orderly return of control to the 
executive at the completion of execution. 

The inputs to this module indicate a successful or unsuccessful completion 
of program execution. In the event termination is required due to operator inter- 
vention, or a detected failure, additional inputs as to the status of the associated 
components are required. 

information processing must accomplish the functions required to assure the 
subsystem is properly configured before control is returned to the executive. 

Upon entry, this module determines if the program has been terminated as a 
result of operator intervention or successful completion of the test. 

In the event of operator intervention, the bookkeeping required to assure that 
the subsystem is properly configured must be accomplished. 

A message indicating completion of execution is presented, and control is 
returned to the executive. 

6. 2. 3 INTERFACE REQUIREMENTS 

This program requires interface with the master executive, OCS executive, 
and the structure subsystem hardware. 

The interface between the Structure Subsystem checkout program and the 
executive architecture is shown in Table 6-4. 

Detailed interfaces which are required in the executive architecture to 
service this program are defined in paragraph 3. 2. 2 of Appendix A of the Task 2 
Final Report. 
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Table 6-4. Structures Checkout Program and Executive Program 
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Section 7 


MAINTENANCE 


There are two aspects of maintenance which entered into the basic study. 
Basic maintenance concepts were provided as part of the baseline resulting from 
the Phase B Space Station study; they are discussed in subsection 7. 1 below. 
Additionally, one of the study tasks was aimed at implementation of an onboard 
electronics maintenance capability. The results of that task are summarized 
in subsection 7.2. 

7. 1 BASELINE MAINTENANCE CONCEPTS 


Maintenance concepts defined for Space Station subsystems are intended to 
facilitate their preservation or restoration to an operational state with a minimum 
of time, skill, and resources within the planned environment. 

7.1.1 GENERAL SPACE STATION MAINTENANCE POLICY 

It is a Space Station objective that all elements be designed for a complete 
replacement maintenance capability unless maintainability design significantly 
decreases program or system reliability. This objective applies to all sub- 
systems wherever it is reasonable to anticipate that an accident, wearout, or 
other failure phenomenon will significantly degrade a required function. Estimates 
of mean-time-between-failure, or accident/failure probability, are not accepted 
as prima facie evidence to eliminate a particular requirement for maintenance. 
Should the accident/failure probability be finite, the hardware is to be designed 
for replacement if it is reasonable and practical to do so. 

As a design objective, no routine or planned maintenance shall require use 
of a pressure suit [either EVA or internal vehicular activity (IVA)J . Where 
manual operations in a shirtsleeve environment are impractical, remote control 
means of affecting such maintenance or repairs should be examined. However, 

EVA (or pressure suit IVA) is allowable where no other solution is reasonable, 
such as maintenance of external equipment. 

Time dependency shall be eliminated as a factor of emergency action insofar 
as it is reasonable and practical to do so. This includes all program aspects of 
equipment, operations, and procedures which influence crew actions. When time 
cannot be eliminated as a factor of emergency action, a crew convenience period 
of 5 minutes is established as the minimum objective. The purpose of the con- 
venience period is to provide sufficient time for deliberate, prudent, and unhurried 
action. 
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7.1.2 ONBOARD MAINTENANCE FACILITY CONCEPTS 

In addition to OCS/DMS capabilities, other onboard maintenance support 
facilities provided on the Space Station include: 

• Special tools for mission -survival contingency repairs such as soldering, 
metal cutting, and drilling, as determined from contingency maintenance 
analyses, although repairs of this type are not considered routine main- 
tenance methods. 

• Protective clothing or protective work areas for planned hazardous 
maintenance tasks (such as those involving fuels, etc. ). 

• Automated maintenance procedures and stock location data for both 
scheduled and unscheduled maintenance and repair activities. 

• Real-time ground communication of the detailed procedures, update 
data, and procedures not carried onboard. 

• Onboard cleanroom-type conditions by "glove box" facilities compatible 
with the level at which this capability is found to be required. 

• Maintenance support stockrooms or stowage facilities for spares 
located in an area that provides for ease of inventory control and 
ready accessibility to docking locations or transfer passages. 

7.1.3 SUBSYSTEM MAINTENANCE CONCEPTS 

Space Station subsystems utilize modular concepts in design and emplace- 
ment of subsystem elements. Subsystem modularity enhances man's ability to 
maintain, repair, and replace elements of subsystems in orbit. Providing an 
effective onboard repair capability is essential in supporting the Space Station's 
ten-year life span since complete reliance on redundancy to achieve the long life 
is not feasible. The need for a repair capability, in turn, requires that a mal- 
function be isolated to at least its in-place re move -and -rep lace level. The level 
of fault isolation is keyed to the LRU, which is the smallest modular unit suitable 
for replacement. The identification of subsystem LRUs is addressed as a 
separate, but interdependent, part of the Onboard Checkout Study. 
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Specific subsystem maintenance concepts, of course, depend upon examina- 
tion of the subsystems. These concepts are discussed in subsequent subparagraphs. 
General subsystem-related maintenance guidelines that have been established for 
the Space Station are: 

• It is an objective to design so that EVA is not required. However, EVA 
may be used to accomplish maintenance/repair when no other solution 
is reasonable. 

• Subsystems will be repaired in an in-place configuration at a level that 
is acceptable for safety and handling, and that can be fault -isolated and 
reverified by the integrated OCS/DMS. This level of maintenance is 
referred to as line maintenance and the module replaced to effect the 
repair is the LRU. 

• A limited bench-level fault isolation capability will be provided on the 
Space Station, but is only intended for contingency (recovery of lost 
essential functions beyond the planned spares level) or for development 

purposes. Limited bench-level support is also provided in the form 
of standard measurement capabilities which are used primarily to 
reduce the amount of special test equipment required. 

• Subsystem elements, wherever practical, will be replaced only at 
failure or wearout. Limited -life items that fail with time in a manner 
that can be defined by analysis and test will be allowed to operate until 
they have reached a predetermined level of deteriorated performance 
prior to replacement. Where subsystem downtimes for replacement or 
repair exceed desirable downtimes, the subsystem will include backup 
(redundant) operational capability to permit maintenance. Expendable 
items (filters, etc. ) will be replaced on a preplanned, scheduled basis. 

7. 2 ONBOARD ELECTRONIC MAINTENANCE (STUDY TASK 3) 


The objective of this task was to generate recommendations of supporting 
research and technology activities leading to implementation of a manned electron- 
ics maintenance facility for the Space Station. Early in the task it became apparent 
that attention could not be confined to a central maintenance facility; it was neces- 
sary to refocus the task to address implementation of an on-board maintenance 
capability encompassing in-place as well as centralized maintenance activities. 

The critical questions are the following: 

• What is the optimum allocation of onboard maintenance functions 
between in-place and centralized maintenance facility locations? 



• What is the optimum level of onboard repair (i.e. , to line-replaceable 
unit, subassembly or module, piece part, or circuit element)? 

7.2.1 MAINTENANCE CYCLE 

In order to place the task in the proper context, a generalized Space Station 
electronic maintenance cycle is depicted in Figure 7-1. 

A convenient place to enter the cycle is with detection of a fault ("In-Place 
Maintenance" block). The fault is isolated to a Line Replaceable Unit (LRU). The 
affected subsystem is restored to full capability by replacing the failed LRU with an 
operable one from spares storage. 

The failed LRU is taken to a maintenance facility (assumed for the moment 
to have a fixed location in the Space Station) where it is first classified. as repair- 
able or non-repairable. Classifications will likely be predetermined, and a listing 
should be retained in the Data Management Subsystem. If the LRU is non-repairable, 
it is placed in segregated storage. If the LRU is repairable on board, the fault is 
further isolated to the failed Shop Replaceable Assembly (SRA). The LRU is then 
repaired by replacing the failed SRA with one from spares storage. The repaired 
LRU is then calibrated (if necessary), and its operation verified before it is placed 
in spares storage. 

Logistics requirements (replacement LRUs and SRAs needed) are transmitted 
to ground-based logistics support functions by RF communications and/or Space 
Shuttle. Failed units are taken away from and replacement units are delivered to 
the Space Station by the Space Shuttle. 

7. 2. 2 SUMMARY OF RESULTS 

The study confirmed and emphasized the necessity of onboard maintenance for 
any maimed mission of any complexity and duration measured in months (up to 10 
years for Space Station). Formulation of recommendations for implementing such 
a capability required consideration of other topics first, and achievement of 
certain interim results. The principal conclusions of this study task are sum- 
marized below. The analyses leading to them are explained in the Task 3 Final 
Report. 

• Prior studies and developments of in-space maintenance have empha- 
sized justification of first-level (in-place) maintenance, fasteners, and 
tools for space application and human factors criteria. Much less 
attention has been devoted to test equipment, maintenance training, or 
definition of shop level maintenance requirements. 
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Figure 7-1. Space Station Maintenance Cycle 

• The baseline subsystem descriptions, checkout requirements analysis, 
and software requirements analysis indicate that approximately 60 per- 
cent of all faults (over a long period) can be isolated to the failed LRU 
automatically under software control, without crew intervention. In an 
additional 27 percent of failure cases, fault isolation to one LRU can be 
achieved by the crew using the onboard Data Management System as a 
tool. In the remaining failure cases, additional fault isolation capabili- 
ties are needed. This is a good result for a "first iteration" and can 
probably be improved considerably with a modest effort to modify stim- 
ulus and measurement provisions. 

• Crew involvement in scheduled and unscheduled maintenance (including 
participation in fault isolation) is estimated to average 7. 2 manhours per 
week over the total mission time. This estimate is most sensitive to 
equipment reliability and levels at which onboard repair is performed. 

It is affected little by the efficiency of automated fault isolation under 
control of the Data Management Subsystem (DMS). 
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• The recommended approach to maintenance in the baseline Space Station 
is in-place removal and replacement of LRUs, without attempts to repair 
LRUs onboard, if the resupply interval is less than nine months. Onboard 
spares should be LRUs. 

• For long resupply intervals or non-resupplied missions (as in a manned 
interplanetary mission), in-place maintenance should be by removal and 
replacement of LRUs. Repair of LRUs should be by removal and replace- 
ment of Shop Replaceable Assemblies (SRAs). Onboard spares should be 
SRAs. 

• The Earth-orbital Space Station should include provision for development 
of onboard maintenance capability and techniques applicable to long dura- 
tion non-resupplied missions and/or the larger, more complex Space 
Base. 

• The baseline subsystem descriptions are at such a level of detail that 
precise specification of onboard tools and test equipment is neither 
feasible nor desirable. Anticipated needs identified qualitatively in the 
study are: (1) a portable test module to supplement software fault isola- 
tion as well as to assist mechanical adjustments and calibrator, (2) hand 
tools for removal and replacement of electronic assemblies, (3) devices 
for transporting and positioning spare assemblies, and (4) a central 
maintenance/repair bench. 

• Several tasks have been identified and recommended for future perfor- 
mance, as part of a system study/design program or as separate 
supporting research and technology tasks. The principal ones deal with 
(1) development of a portable test assembly, (2) development of a repair/ 
test bench with special provisions for small parts retention and for de- 
bris collection, (3) design for accessibility of test points and subassem- 
blies, and (4) devices for transporting equipment within the Space Station. 

The foregoing conclusions apply to the Modular Space Station as well as the 
33-foot diameter, four-deck configuration. 

The results of the study rest upon several assumptions and estimates, 
derived wherever possible from related experience. The results are not sensitive 
to small variations of the assumed or estimated values, except for equipment fail- 
ure rates, which are most influential. Furthermore, it has not been practicable to 
pursue all trade analyses to include all relevant factors. Nevertheless, the study 
has generated valid insights into Space Station onboard maintenance and useful 
visibility of the path to implementation of that capability. 
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